Many computer systems can be described as a modular collection of interacting hardware and software component devices. Proper operation relies on the ability of such devices to recognize each others' presence and appropriately address communications to an intended target. For example, when a peripheral device is connected to a computer system, it is desirable that the peripheral device and computer system should register each others' presence and take steps to enable communicative coupling between peripheral and computer. Manual, automatic and semi-automatic functions supporting such features have long been known in general, including hot plugging and plug-and-play architectures.
For example, when a USB™ device is connected to a computer, the computer system may automatically detect the device and proceed to enumerate it. USB™ enumeration typically refers to the process by which a host computer extracts a description of the number and types of communication channels, pipes or endpoints that are associated with a USB™ device, and configures means for communication with the USB™ device. The computer system may also determine the type of USB™ device, for example by retrieving one or more descriptors. Subsequently, the computer system may load and configure a device driver for facilitating interaction with the USB™ device. There may be several USB™ devices connected to the computer system.
Once devices are registered and communication means and/or parameters established, information relevant to inter-device communication is typically stored in a predetermined portion of the computer system's memory. For example, addresses and descriptors identified during USB™ enumeration are typically stored on a computer system's hard drive, RAM, or other rewritable memory. For example, computer systems having operating systems such as Windows™, Linux™, Unix™, Unix-like systems, or POSIX-compliant systems may store this information in a format particular to the operating system being used. The manner of retrieving the information, for example when selecting or configuring a device driver, therefore depends on the particular operating system in use.
As a particular example, currently available distributions of Linux™ support interaction with USB™ devices using commands such as “read( )” and “write( )” To interact with a USB™ device, such commands are addressed to a device handle associated with the USB™ device. In Linux™, device handles typically exist as file handles in the “/dev” directory off the root directory. For each endpoint of a USB™ device, there is a file handle of the form “/dev/ttyUSBn,” where “n” represents a number assigned by Linux™ during enumeration. Communication with an endpoint can be performed by reading from or writing to the appropriate file handle. The assigned numbers “n” are typically assigned in ascending order, starting from zero, such that each endpoint (or possibly group of endpoints) receives a unique number. However there may be no predictable or consistent correspondence between USB™ endpoints and the file handle name. For example, “n” need not increase incrementally. Rather, numbers may be assigned to new endpoints in an ad-hoc manner, based on what numbers are already assigned. Therefore, software or device drivers cannot tell which file handle to use for communication with a particular endpoint by inspecting the contents of the “/dev” directory.
One potential solution to the problem of determining which device handle is associated with a particular USB™ device or endpoint is to use trial and error methods. For example, a list of all entries of the form “/dev/ttyUSBn” could be collected, and a trial communication could be performed using each device handle until the appropriate handle for communicating with the desired USB™ device or endpoint is found. However, this approach is cumbersome and can undesirably affect operation of the USB™ devices. For example, if the USB™ devices or endpoints are not compatible with the trial communication, their operation may be interrupted and have to be restarted, critical memory may be overwritten or destroyed, or other undesirable effects may occur. Moreover, device restarts may compound the problem as they may affect the device handle associations partway through such a trial and error approach. In addition, on a given computer system, there is no guarantee that the desired device handle, once discovered, will not change for example due to a re-enumeration event. This compounds the problem of using a cumbersome method such as a trial and error method for determining which device handle is associated with a particular USB™ device, since such methods must be repeated periodically.
Linux™ version 2.6 includes a feature called the sysfs file system. Sysfs includes a file system directory which provides an organized representation of devices and drivers recognized by the Linux™ system. For each device or driver added to the computer system, a directory in sysfs is created. The parent/child structuring of subdirectories within the /sys/devices/ directory reflects the physical layout of devices. Other subdirectories, such as /sys/bus, /sys/class and /sys/block contain other structural information regarding devices. However, while sysfs organizes device information, it remains an essentially passive data repository, which can change over time and may be difficult to interpret.
A Linux™-based module called “udev” was introduced in 2003 and described in “udev—A Userspace Implementation of devfs,” by Greg Kroah-Hartmann, in Proceedings of the Linux™ Symposium, Jul. 23-26, 2003. Udev interacts with the hierarchical representation of all physical and virtual devices available through the sysfs file system, and with notifications of device addition and removal events provided through /sbin/hotplug. The udev module allows for several features including persistent naming of devices, notification of device changes, flexible device naming schemes, and dynamic resource assignment. However, while the udev module operates to dynamically create device files and simultaneously associate them with persistent device names, it does not provide for identifying already created device files. In addition, udev cannot identify a device unless the user has previously set up identification parameters, which can be time-consuming.
More generally, when two or more computer component devices are connected together, at least one of the devices may store two separate sets of information: a set of descriptors identifying the other devices, and a set of communication handles for communicating with them. However, these two sets of information may not be closely associated with each other. Furthermore, each device may have multiple communication handles associated therewith. Therefore, it is often difficult to determine which communication handle is associated with a particular component device, and which one is to be appropriate for a particular type of communication when the need arises.
An additional problem in the prior art is that, even after device handles are identified, they may subsequently change due to restarting or reconnection of a device.
Therefore there is a need for an improved method and apparatus for identifying a desired device handle in a host computer system that is not subject to one or more of the above limitations.
This background information is provided for the purpose of making known information believed by the applicant to be of possible relevance to the present invention. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art against the present invention.